fix(examples): allocate geo_z instead of geo_y in 3D readGeometry - #375

## Summary

In the `readGeometry()` helper of the C API examples, the 3D branch
allocated `*geo_y` a second time instead of allocating `*geo_z`. The
subsequent `fscanf` then wrote through the (NULL) `*geo_z` pointer,
causing a segmentation fault whenever 3D geometry input was used.

## Root cause

```c
*geo_x = (double *)malloc(n * sizeof(double));
*geo_y = (double *)malloc(n * sizeof(double));

if (dimension == 3)
{
    *geo_y = (double *)malloc(n * sizeof(double));   // leaks geo_y,
                                                      // geo_z never allocated
    for (int i = 0; i < n; i ++)
        if (3 != fscanf(fin, "%lf %lf %lf\n",
                        *geo_x + i, *geo_y + i, *geo_z + i))  // write to NULL
```

Callers initialize `gz = NULL`, pass `&gz`, and later `free(gz)` — so
`*geo_z` is expected to be allocated here.

## Fix

Allocate `*geo_z` in the 3D branch (one-word change in each of
`examples/amgx_capi.c` and `examples/amgx_capi_multi.c`).

## Testing

Full AMGX build/tests were not run (GPU/CUDA-heavy dependency).
Instead, `readGeometry()` was extracted verbatim into a standalone C
harness and compiled with `gcc -Wall -Wextra` (clean):

- Fixed version: 3D and 2D geometry files parse correctly, `geo_z`
  values verified -> PASS (exit 0).
- Original (pre-fix) version: segfaults on the 3D input
  (exit 139, SIGSEGV) — confirming the bug and the fix.

## Why existing tests missed it

The example programs are not exercised with 3D geometry input files by
any automated test; the 2D path (the common case) works fine because
`geo_z` is unused there.